UMA’s Data Verification Mechanism
Adding Economic Guarantees to Blockchain Oracles for Truly Decentralized DeFi Contracts
TL;DR: We’ve built a decentralized oracle that’s designed to solve the GIANT pain point faced by most DeFi projects—the problem of centralized and corruptible oracle price feeds.
Three weeks ago we introduced our Data Verification Mechanism (DVM), a blockchain oracle with economic guarantees around the cost of corrupting an oracle system.
This follow-up post offers an high-level overview of the system and explains why we believe that an oracle with economic guarantees is a necessary building block for creating DeFi products that scale.
The Oracle Problem… is that Every Oracle Can Be Corrupted!
Here’s our bold claim: every blockchain oracle is corruptible, which means every smart contract that relies on off-chain data is corruptible and manipulatable at some price. This means your DeFi smart contract could be at risk.
Our logic: on a public, permissionless blockchain like Ethereum, there are no rules or laws against bribes or corruption. And since any oracle system fundamental has a data reporter or set of reporters, there is some bribe that can be paid to corrupt those reporters.
It’s useful to analogize this to the fiat world. Suppose Alice and Bob each contribute $500k to enter a fiat world “legal” contract that pays out $1mm according to the value of some data source (what “oracles” are called in the fiat world). Now suppose Bob likes to cheat. He could bribe and corrupt this data source to pay himself the full $1mm (and cheat Alice out of $500k). He has an incentive to do this if the bribe he needs to pay is less than $500k.
Bob would happily bribe the data source, except that in the fiat world, Alice can take Bob to court and ultimately send him to jail. So Bob stays honest.
Of course, on the blockchain, we have no jail. Bribes are totally legal. Bob is free to bribe any oracle or any participant to his heart’s content.
Because of blockchain’s pseudo-anonymity, this scales to be a huge problem. Say Bob enters 10 contracts where he could steal $500k/contract by bribing the oracle used to value all of those contracts. That’s a $5mm incentive to bribe this oracle. Now say you have 10k contracts, 100k contracts etc, all using this same oracle… Bob could engineer a scenario where he could earn hundreds of millions in profits with a relatively small bribe to this single point of failure.
Critically, this means that if DeFi keeps growing, the incentive to corrupt the price feeds powering DeFi contracts will grow to become very large. Ultimately, this limits how much DeFi can scale. Until we can prove that an oracle cannot be profitably corrupted, we cannot move trillions of dollars of economic value cannot move into DeFi. This the problem that the DVM oracle design is attempting to solve.
Defining an “Honest” Oracle
Since all oracles are corruptible at some price, there exists some bribe that can corrupt an oracle mechanism and produce dishonest behavior. We define the smallest possible successful bribe as the Cost of Corruption (CoC).
There also exists some maximum amount of profit that can be stolen by corrupting the oracle. We define this maximum profit as the Profit from Corruption (PfC).
It follows that, in order for an oracle to remain honest, the cost of corruption must always remain greater than the profit from corruption, i.e.: CoC > PfC.
This is what we call an economic guarantee: if we can prove that the CoC > PfC inequality holds, we will have proven that there is no economic incentive to corrupt the oracle. This means Bob, the cheater, cannot profit by bribing the system no matter how many contracts he enters.
Building an Oracle with Economic Guarantees
Ok great… we know we want to enforce this CoC > PfC thing… how do we do this?!?
Well it turns out that building an oracle with economic guarantees requires three things:
- Create a system to measure the Cost of Corruption (CoC)
- Create a system to measure the Profit from Corruption (PfC)
- Design a mechanism to keep CoC > PfC and prove it will work
The details of how exactly we do this are fully articulated in our DVM whitepaper—you should read it! For those short on time, here’s the high level overview:
Step 1: To measure the Cost of Corruption, the DVM uses a Schelling-Point style voting system with tokenized voting rights. Token holders vote on disputed price points and are paid a reward for voting honestly and penalized otherwise. As long as there is an honest majority, voters will vote correctly. This means the Cost of Corruption is the cost to buy control of 51% of the voting tokens.
Step 2: To measure the Profit from Corruption, all contracts using the system are required to register with the DVM and report the value that could be stolen if their price feed was corrupted (this is the contract-specific PfC value). The DVM then sums each contract’s PfC into a system-wide PfC number.
Step 3: The CoC > PfC mechanism in enforced by a variable-fee policy. This is where it gets fun! Let’s use some numerical examples:
Suppose there is a system-wide PfC value of $100mm. This means that in a worst-case attack, if an attacker (Bob) can successfully corrupt the price feed, they can extract $100mm from the system. To corrupt the system, Bob needs to buy or control 51% of the voting tokens. This means the Cost of Corruption for the system is whatever it costs to buy 51% of the tokens.
Enforcing our CoC > PfC inequality requires keeping the cost of 51% of the voting tokens above the $100mm PfC number. In other words, we need to keep the total market cap of the voting tokens above $200mm. If the market cap drops below this level, Bob would be able to pull off a profitable attack.
The DVM does this by continuously monitoring this CoC > PfC relationship and initiating programmatic, repeated, token buybacks if the voting token price drops below target. All purchased tokens are burned, reducing token supply (which increases the market cap). The funds needed to conduct these buybacks are raised by levying pro rata fees on the contracts using the system.
Importantly, the DVM system is designed to levy the lowest fees possible while maintaining the CoC > PfC economic guarantee. As such, the system is not rent-seeking — it is designed to minimize the fees required to maintain the security of the system. A fascinating result of this design is that when market participants expect growth in the future usage of the protocol, this expectation of growth can maintain the CoC > PfC inequality without the DVM levying any fees at all.
The full math analysis of this design is in the whitepaper—read it!
What’s Next
We will soon be releasing a framework for how to best write financial contracts that make use of the DVM. These contract templates will enable developers to create bilateral swaps on anything, decentralized derivative exchanges (think decentralized BitMEX), and pretty much any other financial product you can dream up. If you are DeFi project, developer, or financial engineer interested in playing with our infrastructure, we’d love to hear from you and learn about what you’re excited to build!
- Email us: hello@umaproject.org
- DM and/or follow us on Twitter @UMAprotocol
- Follow us here on Medium
- Sign up for early access at umaproject.org
- Read our whitepaper / check out our GitHub
